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Abstract: In the paper we propose general framework for Automatic Secret Generation and Sharing 
(ASGS) that should he independent of underlying secret sharing scheme. ASGS allows to prevent the 
dealer from knowing the secret or even to eliminate him at all. Two situations are discussed. Eirst 
concerns simultaneous generation and sharing of the random, prior nonexistent secret. Such a secret 
remains unknown until it is reconstructed. Next, we propose the framework for automatic sharing of a 
known secret. In this case the dealer does not know the secret and the secret owner does not know the 
shares. We present opportunities for joining ASGS with other extended capabilities, with special 
emphasize on PVSS and pre-positioned secret sharing. Einally, we illustrate framework with practical 
implementation. 
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1. INTRODUCTION 

Everybody knows situations, where permission to trigger certain action requires approval of several 
selected entities. Equally important is that any other set of entities cannot trigger the action. 

Secret sharing allows to split a secret into different pieces, called shares, which are given to the 
participants, such that only certain group (authorized set of participants) can recover the secret. 

To make this requirement realistic, one should avoid situations were some of the protocol parties have 
dominant position. This reasoning resulted in creation of fame work for ASGS. 

Secret sharing schemes (SSS) were independently invented by George Blakley [2] and Adi Shamir 
[13]. Many schemes have been presented since, for instance, Asmuth and Bloom [I], Brickell [5], 
Karin-Greene-Hellman (KGH) [8]. SSS can work in two modes: 

1. Split control. In this case the secret itself is important, hence protected by distributing its pieces to 
different parties. This mode is, for instance, applied to protect proprietary secrets (e.g., Coca-Cola 
secret formula) or cryptographic keys. 

2. Authentication. The content of the secret is secondary to the fact that only participants from the 
authorized set are able to recover it. This property allows to authenticate/identify parties taking part in 
the protocol. If they are able to recover the right secret, they are the chosen/right ones. 

Once secret sharing was introduced, people started to develop extended capabilities. Some of 
examples are: detection of cheaters and secret consistency verification (e.g. [II], [12], [14]), multi¬ 
secret threshold schemes (e.g., [11]), pre-positioned secret sharing schemes (e.g., [11]). The other class 
of extended capabilities focuses on anonymity, randomness and automatization for secret sharing 
procedures. Anonymous and random secret sharing was studied by Blundo, Giorgio Gaggia, Stinson in 
[3], [4]. Some of ideas in automatic secret sharing and generation originate from the same field. 
Although verification capacity can protect against cheating, it usually comes at the price. This fact is 
related to the paradox stated by David Chaum, that no system can simultaneously provide privacy and 
integrity. Alternative approach proposed recently [9] seems to be promising shortcut. Nevertheless, the 
simplest way to stop cheating is to eliminate misbehaving parties from the protocol. 

Dealer of the secret is the entity that assigns secret shares to the participants. Usually, the dealer has to 
know the secret in order to share it. This gives dealer advantage over ordinary secret participants. 

There are situations, where such advantage can lead to abuse. Eor instance: Often happens, that secret 
dealer is not the secret owner (e.g., owner hired the dealer to share the secret due to the task 
complexity). In this situation owner has to disclose secret to the dealer. Such knowledge allows Dealer 
to make use of the secret without cooperation of the set of authorized participants. 

Having in mind two modes of operation for secret sharing schemes, we propose two solutions: 



1. Automatic secret generation and sharing of random, prior nonexistent secret. It allows computing 
and sharing the secret “on the spot”, when it is not predefined. This is typical situation for 
authentication mode. The secret is generated at random also the secret owner is can he eliminated. 

2. Automatic sharing of a known secret. Using such an automatic procedure owner can easily share 
the secret, without any Dealer of the secret. 

It addresses problem of secret owner not trusting the dealer. It can have added feature, that even secret 
owner knows neither secret shares, nor their distribution. The later decreases chances of owner 
interfering with the shared secret. 

The goal of the paper is to propose general framework for two cases characterized above. The 
ASGS framework/paradigm is independent of underlying secret sharing scheme. Implementation 
details will be strongly dependent on characteristic of particular scheme. Hence in the framework part 
of the paper we provide only functional descriptions of procedures and algorithms. In the appendixes 
we give example of one such implementation. 

The article has the following outline: section 2 is devoted for preliminaries, sections 3 contains 
description of automatic secret generation and sharing of random secret, while section 4 deals with 
automatic sharing of known secret. In section 5 we briefly discuss security requirements for ASGS. 
Next, we state Basic Property Conjecture, which describes sufficient conditions allowing to implement 
ASGS for any SSS. Last section of the main part of the paper contains open problems and concluding 
remarks. Example of practical implementation for KGH method (see [8]) is given in appendixes. 
Appendix A provides all preliminaries needed further in the example, while appendixes B, C 
correspond to sections 3,4 of the paper, respectively. Appendixes B, C are independent and can be 
studies separately. In appendix D we present verification procedure that checks consistency of the 
secret shares resulting from ASGS. 


2. PRELIMINARIES 

First, let’s start from some philosophical background. Longman’s “Dictionary of Contemporary 
English” describes secret, as “something kept hidden or known only to a few people”. Still, there are 
few basic questions about nature of the secret, which need to be answered: 

When does the secret existence begin? 

Can secret exist before it is created? 

Can secret existence be described by binary variable or is it fuzzy? 

Can secret exist unknown to anyone; do we need at least one secret holder? 

If secret is shared, how one can verify its validity upon combining the shares? 

What does it mean that secret is shared or distributed? 

Search for answer to the last question resulted in the development of secret sharing schemes, as 
described in introduction. As for preceding ones, answers were taken for granted without posing the 
questions. At that time such approach was natural, because the problem stated was to providing split 
control over known secret. This problem is well studied and quantitative answers are formulated in the 
language of information theory. 

We consider situations different from initial one, hence we have to answer the questions for each case 
considered. The answers setup general framework for ASGS, independently of underlying secret 
sharing scheme. We state only qualitative description and hope that some day it will reach the 
quantitative level. 

In the paper, we make use of automatic devices and procedures. We favor the approach, that in order 
to ease analysis and enhance security, they should be as simple as possible. It seems that possibility of 
successful implementation of ASGS for the given SSS is related to existence of some 
basic/fundamental property of that scheme. In the section 5 we state conjecture about this fact, while 
in appendix A, we state such property for KGH method. 

In general framework at least two such devices will be needed. First is random number generator; with 
output strings having good statistical properties (e.g., see [10]). Second comes the accumulator, which 
is a dumb, automatic device that memory cannot be accessed otherwise than by predefined functions. 
Let’s introduce two more concepts that are needed: 



Secure communication channel. In this paper we assume that all the communication between 
protocol parties is done in the way that only communicating parties know the plaintext. Whenever we 
use command like “send”, we presume that no third party can know the message contents. There is 
extensive literature on this subject; interested reader can consult for instance [11]. 

Encapsulation. Entities and devices taking part in the protocol can exchange information with others 
only via interface. Inner state of the entity (e.g. contents of memory registers) is hidden (encapsulated) 
and remains unknown for external observers. Encapsulation, originating in object-oriented paradigm 
(e.g., see [6]), is widely used in various fields of computer science. 

Einally, last but not least, the notation: 

Let and be secret shares in some SSS and 5 denote the secret shared. Ss K , where K is the 
secret space. 

C{U ) denotes combiner algorithm for the given SSS that operates on the authorized set of shares U . 
U^^'’ = } and t/® ={sp\s 2 ^\...,s®} are two authorized set of secret shares such that 

|[/''^| = d, |t/(2)| = „ and c(f/W)=5 = c(f/(2^). 

[7**^ is called authorized set of primary secret shares that is used for verification of . Set is 
called authorized set of user secret shares or, for the reasons that will become clear later, authorized set 
of master secret shares. 

denotes share participant that was assigned to the secret share 5*"^ from t/^"^. 


3. AUTOMATIC SECRET GENERATION AND SHARING 

In this section we discuss automatic secret generation and sharing of random, prior nonexistent secret. 
As promised first we provide answers to the questions from the section 2. 

In our approach, the secret existence begins, when it is generated. However, for the secret that is 
generated in the form of distributed shares, moment of creation comes when shares are combined for 
the first time. Before that moment, secret exists only in some potential (virtual) state. Nobody knows 
the secret, though secret shares exist, because they have never been combined. In order to assemble it, 
cooperation of authorized set of participants is required. In such a situation, there are only two ways to 
recover secret: by guess or by cooperation of participants from the authorized set. The first situation 
can be feasibly controlled by the size of the secret space, while the other one is the legitimate secret 
recovery procedure. 

Once shares are combined, the secret is recovered. Recovered secret has to be checked against 
original secret in order to validate it. Hence, there must exist primary (template) copy of the secret. 
This can be seen from different perspective: authentication mode of operation for SSS should allow to 
identify and validate authorized set of participants, so, the template copy is required for comparison. 
Eor instance, consider opening bank vault. One copy of the secret is shared between bank employees 
that can open vault (the authorized set of secret participants). Second copy is programmed into the 
opening mechanism. When the employees input their combined shares, it can check whether they 
recover proper secret. 

ASGS allows computing and sharing prior nonexistent secret “on the spot”. This is typical situation 
for authentication mode. ASGS allows to prevent the dealer from knowing the secret or even to 
eliminate him at all. Using proposed procedure, it is also possible to design secret that remains 
unknown till the time it is recovered. Such secret cannot be compromised in the traditional meaning, 
because it does not exist until it is recovered. The secret is generated at random. This feature is 
important even without eliminating the owner. It makes the secret choice “owner independent”; hence 
decrease chances for the owner related attack. Eor instance, users in computer systems have strong 
inclination to use as the passwords character strings that have some meaning for them. The most 
popular choices are spouse/kids names and cars’ registration numbers. 

ASGS should allow automatic secret generation, such that: 

a. The generated secret is random. 

b. Two copies of the secret are created. Both secret copies are created in a distributed form. 



c. Nobody knows the secret till the shares from the authorized set are combined. 

d. Distributed secret shares can be replicated without compromising the secret. 

e. Replication of the source set into the target set having different number of elements has to be 
supported 

f. The secret shares resulting from replication have different values then the source shares. 

g. ASGS supports same type of access structure as underlying SSS. 

To meet above specification we introduce the following algorithms: 

Algorithm 1: SetGenerateM(d ,n). 

Description: SetGenerateM is used to generate two distributed copies of the random secret. It produces 
U and , such that = d , = n . It is automatically executed by the Accumulator. ■ 

So far, generation of secret sets U and U , was described. In order to make use of the secret shares 
they should be distributed to secret shares participants. Shares distribution is carried out via secure 
communication channel. 

When I = 1 , one is dealing with degenerate case, where = S . It is noteworthy that, when 
|c/ I > 1 , shares assignment to different participants allows to introduce extended capabilities in 

the secret sharing scheme. One of instances could be split control over secret verification procedure. 
Algorithm SetGenerateM allows only two authorized sets of secret shares to be created. Usually, 
onlyU*^^ will be available for secret participants, while is reserved for shares verification. Often, 
it is required that there are more than one authorized sets of participants. On the other hand property, 
used in Algorithm 1 does not allow creating more than two authorized sets. The problem is: how to 
further share the secret further without recovering it’s value? 

This question can be answered by distributed replication of U into U . Although all participants 
take part in the replication, they do not disclose information allowing secret recovery. Any of 
Pj^^^ should obtain no information about any of 5 ® . Writing these properties formally: 

1. c(u^^^)=c(u(^^)=5. 

2 . knows nothing about any of 

Such approach does not compromise S and allows maintaining all previously discussed ASGS 
features. 

Algorithm 2: EqualSetReplicate(U^^^) 

Description: EqualSetReplicate is used to replicate distributed secret shares into the set with the same 
number of elements. It uses distributed elements of to create and distribute set , such 

= n . It is automatically executed by the Accumulator. ■ 

Algorithm 3: SetReplicateToBigger(U^^\ d ) 

SetReplicateToBigger is used to replicate distributed secret shares into the set with the bigger number 
of elements. It uses distributed elements of to create and distribute set , such 
n = \U 2 \ <\U ^ \ = d . It is automatically executed by the Accumulator. ■ 

Algorithm 4: SetReplicateToSmaller(U^^\ d ) 

SetReplicateToSmaller is used to replicate distributed secret shares into the set with the smaller 
number of elements. It uses distributed elements of to create and distribute set , such 

n = |{/ 2 1 > It/ 3 1 = .It is automatically executed by the Accumulator. ■ 

Remarks: 

1. To obtain many authorized sets of participants, multiple replication of t/*^^ takes place. In such 

instance t/*^^ is used as the master copy (template) for all n>3 . For this reason it is called 
authorized set of master secret shares. 

2. In ASGS secret shares are derived automatically with help of simple devices like Accumulator. 
Nevertheless we recommend, that once distributed, shares should be tested for consistency. Namely, 



whether participants from various authorized set can recover the same secret 5 . Further discussion 
about verification is postponed to section 5. 


Descriptions provided above looks like a “wish list”, while algorithms illustrate only basic ideas and 
provide functional description. Reader that is not satisfied with this level of detail, is invited to read 
example of implementation in appendix B. 


4. AUTOMATIC SECRET SHARING 

In this section we discuss the case where the secret is known, hence more classical, than one presented 
in the previous section. Our contribution comes in two parts: 

1 . description of the method allowing automatic sharing of the known secret using simple 
automatic device; 

2. using first result, we provide outline of the protocol that allows Owner and Dealer contribute 
independently to the process of secret sharing. The protocol may have added feature, that both 
know neither secret shares, nor their distribution. The later decreases chances of Owner interfering 
with the shared secret. Such solution addresses situation where parties of the protocol do not trust 
one another. 

To address remaining questions from the section 2, we postulate, that: 

a. The resulting secret shares are random. 

b. Minimum two copies of the secret have to exist. 

c. At least one of the copies is in the distributed form. 

d. ASGS supports same type of access structure as underlying SSS. 

To share secret S , secret one has to generate set U , ..., }, such c({/ 5 . 

Automatic secret sharing algorithm takes away from the Owner responsibility for proper construction 
of the secret shares. Using such a method Owner can easily share the secret. 

Algorithm 5:FastShare( S,n) 

Description: FastShare is the tool that provides fast and automatic sharing for a known secret. 

Parties of the protocol: Owner, Accumulator (dumb automatic device). 

It takes secret 5 from the Owner and n (number of secret participants). Algorithm is automatically 
executed by the Accumulator beyond Owner control. It returns U , ^ 2 °^, ..., } ■ 

Resulting secret shares are not protected against modification by the Owner. 

Next algorithm SafeShares confidentially shares secret 5 using secret sharing mask M provided by 
the Dealer. In the method the following conditions hold: 

a. Dealer does not know S ; 

b. Owner does not know M ; 

c. Owner does not know secret shares and their assignment to the secret participants 

Algorithm 6: SafeShares 

Functional description of the algorithm follows, while information flow is illustrated on the figure 1. 
Parties of the protocol: Owner, Dealer, Accumulator secret participants 

1. Dealer prepares mask M needed to share the secret. It can be though as anonymous envelopes that 
will be used to hold secret shares. The envelopes are identical and indistinguishable. Their number is 
equal to the number of secret shares. 

2. Owner shares the secret using FastShare , secret shares are placed in the envelopes. The envelopes 
are placed in the um. Each of secret participants is assigned one randomly chosen envelope. As the 
result Owner knows neither distributed shares, nor their assignment to the participants. ■ 

Secret shares, which are protected by the mask, cannot be combined in order to recover the secret. 
Once the shares are distributed by SafeShares, they have to be activated by the algorithm 
ActivateShares. 

Algorithm 7: ActivateShares 

Functional description of the algorithm follows, while information flow is illustrated on the figure 1. 



Parties of the protocol: Dealer, secret participants 

Dealer provides secret participants with the information allowing them to remove the mask (extract 
secret shares from the envelopes). 

Once procedure is completed shares belonging to the participants from the authorized set can he used 
to recover the secret. ■ 

It is interesting to note, that before secret shares are activated, their existence is only potential. To see 
it from different perspective: shares cannot be described by binary variable, they rather fuzzy (with 
coefficient set by the proper activation probability). 

Figure 1. Algorithms SafeShares and ActivateShares 
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Remarks: 

1. Multiple authorized sets. To create single authorized set of participants both algorithms have to be 
executed. Hence, to obtain many authorized sets of participants, multiple executions of SafeShares and 
ActivateShares take place. 

2. Verification. Although much depend on the underlying SSS, proper implementation of FastShares 
should protect against cheating Owner. Yet, unless this fact is proven beyond doubt, we have to 
assume that Owner can modify the shares. After all, it was one of the reasons for introducing 
SafeShares. At presented level of detail one is not able to discuss cheating possibilities that might be 
available for the Dealer. Taking this uncertainty into account we recommend, that once activated, 
shares should be tested for consistency. It means, whether participants from various authorized set can 
recover the same secret S . Testing after activation allows checking both the Owner and the Dealer, as 
well as, whether all algorithms were properly executed. Further discussion about verification is carried 
out in section 5. 






















3. Extended capabilities. Algorithms defined above can be easily adapted to enable pre-positioned 
secret sharing (e.g., see [11]). In order to implement this capability it is enough to separate execution 
of SafeShares from ActivateShares. Hence pre-position secret sharing method can have the form: 

a. Scheme is initialized by SafeShares. 

b. It is activated using ActivateShares, when activation time comes,. 

Again, reader that is not satisfied with this level of detail, is invited to read example of implementation 
in appendix C. 


5. SECURITY RELATED STUFE 

The ultimate goal is to build ASGS that will have same security features as underlying SSS. 
Speaking in the information theory terms: proposed framework should not decrease entropy of S over 
K (entropy of the secret over the secret space). 

Qualitative description of ASGS, which was provided above, allows only making few general points 
concerning security of the framework. We hope, that once implementations appear, these points can be 
expanded into full-blown security proof. Nevertheless we make few points: 

1. Security of the framework. 

Security of the framework is based on the use of secure communication channels, simple automatic 
devices (like Accumulator) and encapsulation principle. All these terms were specified in the 
section 2. Out of these three, the most unsettled are simple automatic devices. We assume, 
convincing security proof can be stated, as long as, devices are kept simple. 

2. Basic Property Conjecture - states sufficient condition to implement ASGS for the given SSS. 

The SSS that has basic property, such that there exist operation(s) O with the following 
characteristics: 

a. Results from performing O on the authorized set of participants (possibly more then one) allow 
determining consistency of the secret shares. 

b. O will not decrease entropy of S over K . 

c. O can be performed on the shares that are protected by envelopes (e.g., encrypted). ■ 

Basic property for KGH method is presented in the appendix A. 

We do not claim that only way to build ASGS for the given scheme is to find such basic property. 
Actually, we cannot say anything about possible alternative approach. Yet, we claim that having 
feasible basic property for the given SSS, we can build ASGS for that scheme. 

3. Verification. 

In ASGS secret shares are derived automatically with help of the simple devices, like Accumulator. 
In some of the algorithms there are also interactions between parties of the protocol (e.g.. Dealer 
provides Owner with mask M ). Hence, we recommend, that once distributed, shares should be 
tested. The test has to provide information, whether participants from various authorized sets can 
recover the same secret S . The testing method depends on underlying scheme, but where possible 
we propose to use some Publicly Verifiable Secret Sharing (PVSS) protocol. It has to support 
possibility of secure testing of already distributed shares. If basic property (as described above) is 
found, construction of PVSS is possible. Handy example for KGH is given in appendix D. 


6. CONCLUDING REMARKS AND FURTHER RESEARCH 

The framework for ASGS was provided. Functional descriptions of the algorithms were given. 
Basic Property Conjecture was stated in the section 5. Finally, an example of ASGS implementation is 
provided in the appendixes. 

A lot still needs to be done. Further research falls into three categories: 

1. Research into ASGS theoretical foundations: 

formulation of ASGS framework in terms of the information theory 




collecting more facts about Basic Property Conjecture, to state it as theorem. The final result 
in this field would be proof of such theorem. 

2. Finding more implementations of ASGS. This includes formal proofs of security for particular 
implementations. 

3. Placing ASGS in the broader framework within secret sharing. For instance, joining ASGS with 
other extended capabilities. 
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APPENDIX A: Preliminaries 


KGH description 

In KGH the secret is a vector of rj numbers 5^ = , S 2 ,■■■, }. Any modulus k is chosen, such that 

k > max( 5 j, S 2 ,-; ). All t participants are given shares that are p -dimensional vectors 

= 1 , 2 ,..., t with elements in Z^. To retrieve the secret they have to add the vectors component¬ 
wise in Zk. 

For k = 2, KGH method works like © (XOR) on p -bits numbers, much in the same way like Vernam 
one-time pad. If t participants are needed to recover the secret, adding f -1 (or less) shares reveals no 
information about secret itself. 

In practice, it is often needed that only certain specified subsets of the participants should be able to 
recover the secret. The authorized set of participants is a subset of all participants. Participants from 
such set are able to recover the secret. The access stmcture describes all the authorized subsets. To 
design the access structure with required capabilities, the cumulative array construction can be used, 
for details see, for example, [7], [12]. Combining cumulative arrays with KGH method, one obtains 
implementation of general secret sharing scheme (see, e.g., [ 12 ]). 

Remarks about procedures and algorithms presented in the appendixes. 

Every routine is described in three parts: 

a. Informal description. It states the purpose of routine, describes what is being done and 
specifies output (when needed). Such description should be enough to comprehend the paper 
and get main idea behind presented methods. 

b. Routines written in pseudocode, resembling high level programming language (say C-H-). 
Level of detail is much higher than in description part. Reading through pseudocode might 
be tedious, but rewarding in the sense that allows appreciate proposed routines in full 
extend. 

c. Discussion (if needed). Methods and results are formally justified. 

Preliminaries for Algorithms 

Notation: 

As described in the section 2 random number generator and the Accumulator are needed. Also, secure 
communication channel and encapsulation have to be supported. 

RAND yields m, obtained from a random number generator. 

ACC denotes the value of I -bit memory register. Register’s functions are: 

ACC.reset sets all bits in the memory register to 0, 

ACC.read yields ACC, 

ACC.store(x) yields ACC - ACC © x (performs bitwise XOR of ACC with the input binary vector x, 
result is stored to ACC). 

The idea of automatic secret generation and sharing, for KGH method, is based on the following 
property of binary vectors. 

Basic property: Let m, ,/ = 1 , 2 ,...,« , such that 


=0, (*) 

1=1 

form the set M . Lor any partition of M into two disjoined subsets Cj, C 2 
(Cl u C 2 = M, Cj n C 2 = 0), it holds: 




0 m, = 0 m,.. ■ 

m^eCj mjE.C2 



Now we present the procedure that generates set of binary vectors M . 

Procedure description: GenerateM creates set of n binary vectors , satisfying condition (*). 
Procedure is carried out by the Accumulator. The procedure returns M = {mj, m 2 , ... ,»!„}. 
Procedure 1: GenerateM( n ) 

Accumulator: 

ACC.reset, 

for / = 1 to n-l do 
m, ;= RAND 
ACC.store (m,) 
save m,. 
end //for 
= ACC.read 
save 

return m 2 , ... 

end // GenerateM 

Discussion: We claim that the generated set M satisfies condition (*). First, statistically independent 

n-\ 

random vectors m,-, i = 1 , 2 ,..., n-l are generated, while ni„ = 0 m ^, so 


n 1 

''n-l ^ 


''n-l ^ 


''n-l ^ 

© nr,. = 

© m- 

©m„ = 

© m- 

© 

© m- 

(=1 

Ki=l J 


{.i=l J 


\i=t y 


Further in the paper whenever we make reference to set M , we mean set as defined above. 


APPENDIX B: Procedures and algorithms for an automatic secret generation and sharing of 
random, prior nonexistent secret. 

SetGenerateM description: It creates U and U , such that |[/ ^'^ | = d , |[/ *^' | = n. First, GenerateM 

is used to create set M , such \M\ = d + n . Next, M is partitioned into U and U . The Accumulator 
executes algorithm automatically. 

Algorithm 1: S etGenerateM( d ,n) 

Accumulator: 

GenerateM( d + n) 

for / = 1 to J do // preparing U 

( 1 ) 

s] := m,. 

save 
end //for 

for i = d + l to d + nAo H preparing U 
j:=i-d 

sf'' := m- 

save sf^ 
end //for 

return }, } 

end// SetGenerateM ■ 



Authorized set replication (same cardinality sets) 

The authorized set satisfies: = « , t/® t/® 

Algorithm EqualSetReplicate replicates set into the set . It makes use of the procedure 
SetReplicate. 

SetReplicate description: SetReplicate takes and M , with cardinality \m\ = 2- . Hence 

M ={mi, m 2 , ... ,}. First, all participants are assigned corresponding vectors m,. Each of 
them performs bitwise XOR on their secret shares and corresponding m,. Operation result is sent to 
the Accumulator. Accumulator adds to form sP^, which later is sent to . As the result, 
simultaneous creation and distribution of U takes place. 

Procedure 3: SetRepUccUe(M 


Accumulator: 



for / = 1 to n 
send m^to 

: cop^ := sP'’ © m- H O) is /-bit vector (local variable) 

end//for 
for / = 1 to n 

P^^"' send cop"’ to Accumulator 
Accumulator: sP^ := cop^ © 

send ^P^to PP^ 
end// for 

endll SetReplicate ■ 

Algorithm EqualSetReplicate is the final result in this section. 

EqualSetReplicate description: EqualSetReplicate takes . It uses SetReplicate to create and 
distribute set U , such p | = |t 7 | . 

Algorithm 2: EqualSetReplicate( 

Accumulator: 

n:= 

M := GenerateM (2n) 

SetReplicate( M 
end// EqualSetReplicate 

Discussion: We claim that EqualSetReplicate fulfils requirements stated in the section 3: 

n n ( \ f n f 2n \ n 

1 . © 5'P = © (i'P © nr; © nr,+„ j= ©5'p © ©wt; =© i'p as requested. 

i=\ /=1 v=l ) v=l ) ^=1 

2 . All sP^ result from XOR of some elements from U with random m,, hence they are 
random numbers. ■ 

Authorized set replication (different cardinality sets) 

For |t/ 2 | I 1 / 3 I there are two possibilities: 

Case 1. SetReplicateToBigger description: SetReplicateToBigger takes d and U^^'’. It generates M , 
such that ImI = c/. Next, it uses SetReplicate to create and distribute first n elements from . As the 



result participants for i < n have their secret shares assigned. Remaining participants are 
assigned m, (i> n) not used hy SetReplicate. As the result U , such n = |{/ 2 1 < 1 = is created and 

distributed. 

Algorithm 3: SetReplicateToBigger( U^^\d) 
n:= 

M := GenerateM(d + n) 

Accumulator: 

SetRepIicate( M H assigns shares for participants up to , it uses first 2n elements of M 

for i = n +1 to d 
(3) 

■= f^i+n 

send to 
end//for 

end// BiggerSetReplicate 

Discussion: We claim that SetReplicateToBigger fulfils requirements stated in the section 3: 

1. First observe, that: 
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2. For i > n all sf"’ are equal to random numbers m^. For i < n all ^P^ result from XOR of some 
elements from with random m,, hence are random numbers. ■ 

Case 2. SetReplicateToSmaller description: SetReplicateToSmaller takes d and . It generates 
M , such that |m| = n + d-1. Next, it uses SetReplicate code to create n secret shares sP^. First d - I 
shares are sent to corresponding participants P[^"’. Remaining ^P^ ( i e {d, d +1,..., n}) are combined to 
form that is sent to pj^'. As the result , such that n = [[/jI > IC 3 I = d is created and distributed. 

Algorithm 4: SetReplicateToSmaller(U^^\ d ) 

n:= |[/®| 

M := GenerateM {n + d — \) 

Accumulator: 
for / = 1 to n 

send m, to P^^^^ 

P ^^^: (pP^ := 5 p^ © m, // co is /-bit vector (local variable) 
end//for 
for i = \ to d-\ 

pl^^ send typ^ to Accumulator 
Accumulator: := cop^ © 

send sP^to P^^ 
end// for 
ACC.reset 

for i = d to n H all (of^ for i < d were already used 
P^-^^ send 0)P^ to Accumulator 



Accumulator: ACC.store{ ) 
end//for 

= ACC.read H ;= 

i=i 

send to 

end// SetReplicateToSmaller 

Discussion: We claim that SetReplicateToSmaller fulfils requirements stated in the section 3: 
1. First observe, that: 
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2. All result from XOR of some elements from with random m, hence they are random 
numbers. ■ 


APPENDIX C: Procedures and algorithms for an automatic sharing of a known secret . 

FastShare description: It takes secret S and n (number of secret participants). Accumulator 
generates random = \,2,...,n-l . Every 5pHs added to the ACC and simultaneously saved. To 
obtain ip' the secret S is added to ACC. Next, ACC value is read and saved as ip'. Algorithm 
returns {/'”'= {ip', ip', ..., ip'}. 

Algorithm 5:F astShare( S,n) 

Accumulator: 

ACC. re set 

for / = 1 to n-l 
ip' := RAND 
ACC.storei 8^°^) 
save ip' 
end// for 

Owner: Send secret to Accumulator 
Accumulator: 

ACC.store(S) //adding secret to the accumulator 
ip' := ACC.read 

save ip' 

return {/'°'= jip', ip', ..., ip'} 
end!!FastShare 

Discussion: 

1. We claim that FastShare produces random secret shares, due to the fact that all of them originate 
from a random number generator. First n-l shares are purely random, while the last one results from 

n—1 

bitwise XOR of the secret and random number. More formally, ip' = 0 ip' © S . So, ip' is random. 
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2 . All secret shares combine to S . Just observe: 0 = 0 i© s = 0 © I 0 
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SafeShares description: Safe Shares requires cooperation of two parties: Dealer and Owner. First, 
Dealer uses GenerateM to create secret sharing mask M , such that 0 m, = 0. He also creates set K 


of encryption keys , such that @ . M elements are encrypted using corresponding keys from 

k-eM 



rwj 


~kf 



K to form encrypted mask set C . 

m 2 
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_m„_ 


}n_ 
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or M®K = C 


Dealer stores K and sends C to the Owner. Owner shares original secret S using FastShare to obtain 
5^°^. Using C and he obtains U , which elements are randomly distributed to the participants. 
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Participants receive secret shares from S and store them. 
Algorithm 6: SafeShares 
Dealer: 

GenerateM(n) 

ACC.reset 

Owner: 

FastShare(S, n ) 
for / = 1 to n 
Dealer: 

Label generation>: 


ki := RAND 


ACC.store( k^) 

if {i = n AND ACC.read == 6 ) { 
ACC.storei ) Hv&moNe. k^ from ACC 
go to < k^ generation> // generate k^ again 
} // end if 
save 

Ci := m,. © k^ 


send c, to Owner 


Owner: sf'’ :=c,- ©s-"^ 

send s\'’^ to randomly chosen Pj ^ 
Participant Pj : 


:= H share index i is updated 
save 11 participant stores his secret share^ 

end//for 
endlI Safe Shares 


* f G {l,2,..., n} , one participant is allowed to obtain only one secret share. Once is send to particular Pj , this 

participant is removed from the set of participants eligible to obtain secret share. 

^ Secret share that was sent to the participant Pj has now the same index j as the participant. 



Discussion; 


1. Note, that 0 S . So, all secret participants, upon combining their shares, will not receive S . 

i=l 

2. The rest of discussion is postponed after Algorithm 7. ■ 

Activate Shares description: ActivateShares requires cooperation of two parties: Dealer and Owner (of 
the secret). Dealer contacts participant Pj. Once participant’s identity is established participant obtains 

one key from the set K . Participant combines k, with s-^’^ to obtain activated share . Action is 
repeated for all participants. 

The algorithm yields ©/f , where ... 


Algorithm 1'.A ctivateShares 

for / = 1 to « 

Dealer: 

contacts 

starts identification procedure 
if ( identification == 1) sends k, to 7} 

Participant : 

saves s\‘‘^ II activated share is stored 
end//for 

end!!ActivateShares 

Discussion: Once secret shares are activated, S can be recovered by standard KGH procedure. We 

« , . 

claim that 0 = 5 . To see it one has to combine results from two algorithms SafeShares and 

1=1 

ActivateShares : 




= @ © k\‘^^ )= © (q © )== © {m^ © © k\‘^^ )= © (m; 
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i=\ i=\ i=l i=\ 1=1 

One should note that particular participant P- usually obtains two different keys from K . Key 
comes from the Owner embedded in , while comes from the Dealer as a part of 


© 


© 


ActivateShares. This does not make a difference, because 
= ©(m,. © i('’))= ©s}”^ = S (since ©m,. = 0) ■ 


i=\ 


1=1 


i=\ 


/=1 


K®K = Q and 

1=1 


APPENDIX D: Publicly Verifiable Secret Sharing (PVSS) for KGH. 

We propose efficient PVSS for KGH scheme that allows to check whether shares of the secret are 
correctly distributed and protects against cheating dealer. Method provides verification, without 
compromising the secret. Using it, secret participants in various authorized sets, can verify whether 
upon combining they will recover the same value of the secret S . 

PVSS is collection of algorithms that provide method for public verification of secret shares. 
Scheme works for the secret sharing schemes with two or more authorized sets of participants. We 
present the case with two authorized sets of participants. 

First, dealer has to share the secret into two sets U , ^2 ^,..., 5 )^'^}, U ,..., }, 

such that c([/^^^)= © sf^=S= © sf-^ =c{u^^A. 



Once the secret is shared into two authorized sets, DistributeShares&Keys can he used. 

Algorithm description: 

DistributeShares&Keys uses RAND to obtain random encryption keys for the secret shares. For every 
secret share, the key value is sent to the corresponding secret participant. The value of the secret share 
encrypted using derived encryption key is made public. Procedure is performed for both authorized 

sets of participants 

Algorithm 8: D istributeShares&Keys 

ACC.reset 

for / = 1 to h 

.•= RAND 

send 

11 participant obtains his key 

cP=sP@kP 

publish cP 
end// for 
for i = 1 to g 

kP := RAND 
send kP ioPp^ 

11 participant P^ ' obtains his key 

cP=sP@kP 

publish cp* 
end// for 

end// DistributeShares&Keys 

Discussion; 

1 .When algorithm is completed, the following hold: 

a. The encrypted value of secret shares cP , cP are publicly available for all secret shares from 




b. The secret key kj^^ / kj^^ is known only to the participant concerned. 

2. Participants from the authorized set are able to recover the secret. For instance, consider participants 
from encrypted shares are formed as shown on the left-hand side below: 
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shares can be computed, allowing to combine the secret @ 


.( 1 ) 


= S . 


ieU 
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When the keys and the encrypted shares are distributed, the secret participants can verify validity of 
their shares (or check dealer's honesty). The first step is made with the algorithm RecoverXORedKeys. 

Algorithm description: 

RecoverXORedKeys uses Accumulator to combine all secret keys kP IkP. One round: a key from 

is sent to the Accumulator, next a key from is sent. Operation is repeated until all the keys 
are in the Accumulator. 

Algorithm 9: R ecoverXORedKevs(U ) 


ACC. reset 



If {n > m) then countern 
else counter m 

for i = 1 to counter 
Participant \ 

if {n>i) send to Accumulator 
else 5; = 0 to Accumulator 
Accumulator: 

ACC.storef 5^^ j 
Participant : 

if (m>i) send 5^^ to Accumulator 
else 5; = ^ to Accumulator 
Accumulator: 

ACC.storef sj^^) 
end// for 

RecoverXORedKeysACC.read 
end// RecoverXORedKeys 

Discussion: 

1. Method of sending keys to the Accumulator enforce security upon value of combined keys from one 
set. At no point in time, value of the combined keys cannot be recovered using Accumulator contents. 

■ 

Having a way to recover the key, we are ready for algorithm Verify . 

Algorithm 10: Verify /) 

1. Publicly XOR all encrypted secret shares, 
store result in XOREncryptedShares 

2. Run RecoverXORedKeys, store result in 
XORedKeys 

3. If (XORedKeys- - XOREncryptedShares) 
verification POSITIVE 

else verification NEGATIVE 
end// Verify 

Discussion: 

1. We claim that if dealer is honest XORedKeys- XOREncryptedShares. Note that: 



The relation presented above is symmetric in the sense that it does not differentiate between keys and 
encrypted shares. If dealer attempts to cheat (no matter whether in keys and/or encrypted shares), the 
equality will not hold. It is satisfied only when both authorized sets of participants receive the same 
value of the secret. 

2.Because no information is revealed about © or @ (only they XORed value is 
provided), hence verification is secure. ■ 

Algorithm Verify is the final result of this section. PVSS, described so far, works for two authorized 
sets of the secret participants. However, method can be adapted to work for more authorized sets of 
participants. In such a case, the secret keys in DistributeShares&Keys have to be derived for all 
participants. 



